Adaptive Bitrate Streaming (ABS) is a technique used in streaming multimedia over computer networks which is becoming increasingly popular for the delivery of video services. Current adaptive streaming technologies are almost exclusively based upon HTTP and are designed to operate over large distributed HTTP networks such as the internet. Adaptive HTTP streaming (AHS) supports both video on demand and live video, enabling the delivery of a wide range of video services to users.
Most of the adaptive HTTP streaming techniques require a client to continuously fetch media segments from a server. A certain amount of media time (e.g. 10 sec of media data) is contained in a typical media segment. The server provides a manifest file to the client, which manifest file specifies the Uniform Resource Locators (URLs) that the client should request in order to play back the streamed video. Each manifest item identifies a segment of the video. A single video stream may consist of several manifest files, each identifying segments corresponding to a portion of the stream.
There are two main approaches to storing video segments on the server. In a first approach, the entire video is stored in a single file. Each segment has a specific URL and a server side Application Programming Interface (API) is used to map segment URLs into file ranges or byte ranges. In a second approach, the video is stored in multiple files called chunks, with each chunk usually corresponding to a single segment. The manifest file contains the URLs of the individual chunks. An advantage of this second approach is that the client video player uses normal HTTP requests to request the chunks, as each chunk is an individual file. This approach is therefore well supported by existing HTTP architecture.
Client video players may display live or on demand video content immediately, fetching and displaying the video segments as the manifest files are made available. Alternatively, broadcast streamed content may be recorded by a client video player and stored for later display. In this case, the client video player stores the video chunks from the broadcast manifest files, enabling the video chunks to be viewed at a later date. Client storage may be located in the client home, for example in the form of a set top box and hard drive. A new generation of Network Personal Video Recorders (N-PVRs) offers an alternative storage solution, in which a service provider maintains a large number of servers on which a subscriber's media content may be stored. Each individual subscriber is thus offered a private storage area on the network servers.
Network based digital storage offers advantages to the client but places a large demand on the network. This demand may include significant duplication of stored video files; the same digital content may be stored multiple times on the network servers if many subscribers choose to record the same video streams, corresponding to popular films or programs for example. Useful economies of storage could in theory be made through the implementation of shared network storage, in which the same digital content could be accessed by several users.
Despite the potential advantages of shared network storage, there are considerable difficulties with managing client access to shared contents. For licensing and perhaps other legal reasons, it is important that the network PVR is functionally identical to a local PVR. This means that only users who have programmed their personal video recorders to record a particular video stream should be able to access that stream from the shared storage for later viewing. Stored chunk filenames are provided in the manifest files at the time of broadcast and these can be locally stored by the PVR. However, chunk filenames can be guessed, meaning that a personal video recorder which was not programmed to record a video stream may still access the stored video chunks of the stream from the shared storage by guessing the chunk filenames. This is highly undesirable, as users should only be able to access content that they have recorded at the time of broadcast.
A solution to this problem is described in the applicant's patent application PCT/EP2014/052057, whereby chunk filenames are not transmitted to the PVR, but instead are derived from the live stream of video content, possibly by a cryptographic hash.
A problem with that solution is that where content is available at multiple quality levels, a PVR can only access the quality level it initially received. This means that if the PVR recorded the filenames during a period of heavy network traffic, when it would have received the lower quality version of the video content, then played back the file at a later time with much lower network traffic, the PVR would not be able to access the higher quality version of the video content because it would not know the filenames for the appropriate chunks. Similarly, if the PVR recorded the chunk filenames during a period of low network traffic, it could receive the high quality version of the video content and record those filenames. Then, if the video is played back during a time of high network traffic, there may not be sufficient bandwidth available to stream the high quality video chunks, in which case playback will fail.